Correct numerous 20054-D: dynamic initialization errors found on arm+12.2#14108
Conversation
|
@robertmaynard Do you think these are "real issues" that we should fix for C++ standards compliance (like avoiding UB) or are they potentially compiler bugs? Do you see these issues with newer GCC versions or older CUDA versions on ARM? |
These are all real issues that aren't exposed by the x86 compiler. I am still digging into why, but here is the background on why these failures are valid: From the CUDA programming guide A
The simpliest way to understand the above is that the struct block_desc_s {
block_desc_s() {};
explicit constexpr block_desc_s(size_t offset_, uint32_t size_,
uint32_t row_offset_, uint32_t first_row_,
uint32_t num_rows_)
: offset(offset_), size(size_), row_offset(row_offset_),
first_row(first_row_), num_rows(num_rows_) {}
size_t offset;
uint32_t size;
uint32_t row_offset;
uint32_t first_row;
uint32_t num_rows;
}; |
Co-authored-by: David Wendt <[email protected]>
7ed1625 to
81f90cc
Compare
| */ | ||
| struct ColumnChunkDesc { | ||
| ColumnChunkDesc() = default; | ||
| constexpr ColumnChunkDesc() noexcept {}; |
There was a problem hiding this comment.
does default here not meet 14.5.3.1. Device Memory Space Specifiers specifications?
is default not considered as trivial constructor if all non-static members have trivial constructors?
I see usage of default in this same PR.
There was a problem hiding this comment.
I need the constexpr constructor for the byte_stream_s type in page_hdr.cu. I agree that on initial read the = default constructor should be sufficient, but the compiler disagrees.
|
/merge |
Description
Compile issues found by compiling libcudf with the
rapidsai/devcontainers:23.10-cpp-gcc9-cuda12.2-ubuntu20.04docker container.Checklist